Awesome!! Thanks for the hard and quick work!

Reviewed 6 of 6 files at r1, all commit messages.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @irahopkinson)

.github/workflows/publish.yml line 14 at r1 (raw file):

        default: false

jobs:

Should we change the name of this file to release.yml?

.github/workflows/publish-main.yml line 6 at r1 (raw file):

  push:
    branches: [main]
  # DEBUG testing-only - remove this before merge

Reminder to remove before merging :) just resolve when finished

.github/workflows/publish-main.yml line 72 at r1 (raw file):

          cd ./release/app
          CURRENT_VERSION=$(node -pe "require('./package.json').version")
          NEW_VERSION="${CURRENT_VERSION}-${{ steps.load_build_number.outputs.build_number }}"

Semver spec states that build number should be after a +

.github/workflows/publish-main.yml line 72 at r1 (raw file):

          cd ./release/app
          CURRENT_VERSION=$(node -pe "require('./package.json').version")
          NEW_VERSION="${CURRENT_VERSION}-${{ steps.load_build_number.outputs.build_number }}"

Is there a way we can see this build number on the commit names somehow? Or maybe point to the associated commit in the release message (or both haha)? Otherwise could we maybe use the commit short hash here on the version name? Or a timestamp? Thinking about how we can get from a build to a specific commit without digging through logs for every commit :)

Build number is good for human-readable sequential numbers! Timestamp might be a good alternative. I wonder if commit short hash would be worth using if we can't figure out how to associate the commit in some other way.

.github/workflows/test.yml line 19 at r1 (raw file):

jobs:
  test:
    name: Build on ${{ matrix.os }}, .Net ${{ matrix.dotnet_version }}, node ${{ matrix.node_version }}

Should this maybe be "Build and test on ..."?

Reviewable status: 5 of 6 files reviewed, 4 unresolved discussions (waiting on @tjcouch-sil)

.github/workflows/publish.yml line 14 at r1 (raw file):

There is already a release.yml one folder up that controls release drafts in GH. More importantly, this file is named as is in electron-react-boilerplate` so we want to receive any updates from a merge from that.

.github/workflows/publish-main.yml line 72 at r1 (raw file):

Yes, I tried that first but npm version <updated version> command doesn't allow values like 0.0.2+1 (despite it saying that it conforms to semver). Also, strictly anything after the + is build metadata and not necessarily a build number. On the positive side, using - means that although precedence won't work unless they have the same number of digits, it will at least recognise that 2 versions are different (rather than being the same and just having different build metadata).

.github/workflows/publish-main.yml line 72 at r1 (raw file):

We should have this build for every merge to main, but I hadn't really thought about wanting to know which build (app artifact) belongs to which commit. Do you think that is a likely need? Any thoughts on how we get the git short commit in GHA?

.github/workflows/test.yml line 19 at r1 (raw file):

Because of the name at the top of the file it actually reads as "Test / Build on...":

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @irahopkinson)

.github/workflows/publish.yml line 14 at r1 (raw file):

Good call :p thanks for considering!

.github/workflows/publish-main.yml line 72 at r1 (raw file):

Looks like this stackoverflow page might be of some use! I don't currently know how to get this information into the release description or wherever you want to put it, though, as I have almost never done anything in GHA.

I imagine it would be very helpful and near to the level of need. I find it very helpful when debugging problems people have. They (in this case, Glenn) tell us their build number, then we go find what code is running at that build they're using.

This will probably become more useful when the test team starts running tests against each commit to main. Then we can trace which commits introduce test failures from build number.

If this is too much of a burden to figure out, maybe let's just make an issue on it and forget it for now.

.github/workflows/publish-main.yml line 72 at r1 (raw file):

Ah gotcha. That's a bummer. Thanks for explaining! What do you think of padding with zeroes at like 4 or 5 spaces to make every build fully incremental? Like 1.1.2-00004 or something.

You could even use left-pad! Just kidding ;)

.github/workflows/test.yml line 19 at r1 (raw file):

😂 gotcha. Thanks!

Reviewed 1 of 1 files at r4, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @irahopkinson)

I renamed publish-main.yml to package-main.yml (and renamed the workflow to Package) to make it easier for Glenn et al to find the artifacts. Prior to that rename we had 2 folders in GHA named Publish which was too confusing.

Also using the commit hash to distinguish builds greatly simplified things so thanks for that idea @tjcouch-sil.

Reviewable status: 4 of 7 files reviewed, all discussions resolved (waiting on @tjcouch-sil)

thanks for all the hard work!

Reviewed 1 of 1 files at r5, 3 of 3 files at r6, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @irahopkinson)

.github/workflows/publish.yml line 46 at r1 (raw file):

          npm run build

      - name: Install DMG license

Why remove the stuff related to building the dotnet stuff on mac? Because things don't work? Does it make sense to leave it in as comments (assuming this code is correct)?

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @irahopkinson)

.github/workflows/publish.yml line 46 at r1 (raw file):

Just want to discuss without blocking the PR from going through. Feel free to resolve if this is holding up the PR.

I wonder if, alternatively to keeping the code in, it makes sense to point to this removal in the macOS support issue.

Reviewable status: complete! all files reviewed, all discussions resolved

.github/workflows/publish.yml line 46 at r1 (raw file):

This wasn't needed originally but had to be added for a bug in electron-builder (IIRC) which should be doing this internally. After electron-builder was upgraded I hadn't had a chance to check if it was ok to remove - this was a good opportunity to do it.